home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 1134 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.0 KB
  1. Path: engnews1.Eng.Sun.COM!taumet!clamage
  2. From: clamage@Eng.sun.com (Steve Clamage)
  3. Newsgroups: comp.std.c++
  4. Subject: Re: Temporary objects in Std
  5. Date: 17 Apr 1996 15:45:15 GMT
  6. Organization: Sun Microsystems Inc.
  7. Approved: clamage@eng.sun.com (comp.std.c++)
  8. Message-ID: <4l333n$6fo@engnews1.Eng.Sun.COM>
  9. References: <4107cc$101229.223@news>
  10. Reply-To: clamage@Eng.sun.com
  11. NNTP-Posting-Host: taumet.eng.sun.com
  12. X-Nntp-Posting-Host: taumet.eng.sun.com
  13. Content-Length: 2124
  14. X-Lines: 57
  15. Originator: clamage@taumet
  16.  
  17. In article 223@news, peng@dpg.rnb.com (Wei Peng) writes:
  18. >Hi, I'm sure about what the Std says about the lifetime of temp objects (it
  19. >says tmp objects may live longer... or something alike).
  20.  
  21. The old rule was that a temporary must be destroyed no later than the
  22. end of the block in which it was created. Some compilers destroyed
  23. temps immediately, some delayed until the end of the block.
  24.  
  25. The draft standard (which is unlikely to change in this regard) says
  26. that a temporary is destroyed at the end of the complete expression
  27. in which it is created. A "complete expression" is an expression
  28. which is not a subexpression of any other expression.
  29.  
  30. >A sample code. Suppose we have a string object called String, all necessary
  31. >constructors/operators are well defined. Now we have three functions
  32. >
  33. >void doSomething(const char*);
  34. >
  35. >String getString();
  36. >
  37. >const char* getCharStar()
  38. >{
  39. >  return returnString();
  40. >}
  41. >
  42. >Now if we do:
  43. >
  44. >          doSomething(getCharStar());
  45. >
  46. >Obvously this code doesn't work under old C++, where temp objects only
  47. >live within their scope. My impression is that under STD C++ the tmp
  48. >object created by getString() should live long enough so doSomething()
  49. >can safely execute.
  50.  
  51. Your example has at least one typo, but I'm going to assume that
  52. function getCharStar looks like this:
  53.     return getString();
  54. and that class String has an implicit conversion to const char*. (The
  55. standard string class does not have that implicit conversion.)
  56.  
  57. If my assumptions are correct, getCharStar won't work. The return
  58. statement is interpreted as
  59.     return getString().operator const char*();
  60.  
  61. getString returns a temporary String, and the type-conversion member
  62. function is called. At the end of the return statement, the temp String
  63. is destroyed (under both old and new rules), and you are left with a
  64. dangling pointer, which is then returned to the caller.
  65.  
  66. Assuming the existence of a strdup function, you would have to write
  67. something like
  68.     return strdup(getString().operator const char*());
  69. so that the returned pointer continues to point to a live object.
  70. ---
  71. Steve Clamage, stephen.clamage@eng.sun.com
  72.  
  73.  
  74.  
  75.  
  76. [ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
  77. [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
  78. [ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
  79. [ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
  80. [ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]
  81.